\chapter{Reporte de métricas de código de \rc}
\label{recabs_metrics_report}

\begin{tabular}{|c|l|}
\hline
\multicolumn{2}{|c|}{CCCC Software Metrics Report generated Tue Nov 22 20:34:56 2011} \\
 \hline 
 \textbf{Project}       & Summary table of high level measures summed over all\\
 \textbf{Summary}       & files processed in the current run.  \\
 \hline 
 \textbf{Procedural}    & Table of procedural measures (i.e. lines of code, \\
 \textbf{Metrics}       & lines of comment, McCabe's cyclomatic complexity \\
 \textbf{Summary}       & summed over each module.  \\
 \hline 
 \textbf{Object Oriented} & Table of four of the 6 metrics proposed by Chidamber \\
 \textbf{Design}        & and Kemerer in their various papers on 'a metrics suite \\
                        & for object oriented design'. \\
 \hline 
 \textbf{Structural}    & Structural metrics based on the relationships of each \\
 \textbf{Metrics}       & module with others. Includes fan-out (i.e. number of \\
 \textbf{Summary}       & other modules the current module uses), fan-in (number \\
                        & of other modules which use the current module), and \\
                        & the Information Flow measure suggested by Henry and \\
                        & Kafura, which combines these to give a measure of \\
                        & coupling for the module. \\
 \hline 
 \textbf{Other Extents} & Lexical counts for parts of submitted source files which \\
                        & the analyser was unable to assign to a module. Each \\
                        & record in this table relates to either a part of the \\
                        & code which triggered a parse failure, or to the residual \\
                        & lexical counts relating to parts of a file not \\
                        & associated with a specific module. \\
 \hline 
 \textbf{About CCCC}    & A description of the CCCC program.  \\
 \hline 

\end{tabular}

\section{Project Summary}
 This table shows measures over the project as a whole. \begin{itemize}
\item NOM = Number of modules\\ 
 Number of non-trivial modules identified by the analyser. Non-trivial modules include all classes, and any other module for which member
functions are 
identified. 
\item LOC = Lines of Code\\ 
 Number of non-blank, non-comment lines of source code counted by the analyser. 
\item COM = Lines of Comments\\ 
 Number of lines of comment identified by the analyser 
\item MVG = McCabe's Cyclomatic Complexity\\ 
 A measure of the decision complexity of the functions which make up the program.The strict definition of this measure is that it is the
number of linearly 
independent routes through a directed acyclic graph which maps the flow of control of a subprogram. The analyser counts this by recording
the number of distinct 
decision outcomes contained within each function, which yields a good approximation to the formally defined version of the measure. 
\item L\_C = Lines of code per line of comment\\ 
 Indicates density of comments with respect to textual size of program 
\item M\_C = Cyclomatic Complexity per line of comment\\ 
 Indicates density of comments with respect to logical complexity of program 
\item IF4 = Information Flow measure\\ 
 Measure of information flow between modules suggested by Henry and Kafura. The analyser makes an approximate count of this by counting
inter-module couplings 
identified in the module interfaces. 

\end{itemize}
 Two variants on the information flow measure IF4 are also presented, one (IF4v) calculated using only relationships in the visible part of
the module 
interface, and the other (IF4c) calculated using only those relationships which imply that changes to the client must be recompiled of the
supplier's definition 
changes. 

\begin{tabular}{|c|c|c|c|}
\hline 
Metric &Tag &Overall &Per Module \\
 \hline 
Number of modules &NOM & 30 &  \\
 \hline 
Lines of Code &LOC & 663 &22.100 \\
 \hline 
McCabe's Cyclomatic Number &MVG & 56 & 1.867 \\
 \hline 
Lines of Comment &COM & 1271 &42.367 \\
 \hline 
LOC/COM &L\_C & 0.522 &  \\
 \hline 
MVG/COM &M\_C & 0.044 &  \\
 \hline 
Information Flow measure (  inclusive ) &IF4 & 66 & 2.200 \\
 \hline 
Information Flow measure (  visible ) &IF4v & 47 & 1.567 \\
 \hline 
Information Flow measure (  concrete ) &IF4c & 18 & 0.600 \\
 \hline 
Lines of Code rejected by parser &REJ & 110 &  \\
 \hline 

\end{tabular}

\section{Procedural Metrics Summary}
 For descriptions of each of these metrics see the information preceding the project summary table. The label cell for each row in this
table provides a link to 
the functions table in the detailed report for the module in question 

\begin{tabular}{|c|c|c|c|c|c|}
\hline 
Module Name &LOC &MVG &COM &L\_C &M\_C \\
 \hline 
 Address & 0 & 0 & 0 &------ &------ \\
 \hline 
 BySizeResultSender & 34 & 2 & 9 & 3.778 &------ \\
 \hline 
 ChainableSender & 12 & 0 & 15 &------ &------ \\
 \hline 
 ChildrenFunctors & 0 & 0 & 0 &------ &------ \\
 \hline 
 ClientProcessor & 0 & 0 & 0 &------ &------ \\
 \hline 
 DeserializerFunctor & 5 & 0 & 8 &------ &------ \\
 \hline 
 DistributableJobImplementation & 0 & 0 & 0 &------ &------ \\
 \hline 
 DistributableRecursiveProcessor & 152 & 17 & 93 & 1.634 & 0.183 \\
 \hline 
 DistributeAlwaysAllPolicy & 11 & 3 & 8 &------ &------ \\
 \hline 
 DistributeRandomPolicy & 14 & 3 & 8 &------ &------ \\
 \hline 
 FinalSender & 12 & 0 & 13 &------ &------ \\
 \hline 
 FixedLeafsDistributablePolicy & 9 & 0 & 6 &------ &------ \\
 \hline 
 FuDRManager & 64 & 9 & 16 & 4.000 & 0.562 \\
 \hline 
 FuDRProcessor & 32 & 2 & 20 & 1.600 &------ \\
 \hline 
 FuDSender & 12 & 0 & 9 &------ &------ \\
 \hline 
 InmediatelySender & 17 & 0 & 11 &------ &------ \\
 \hline 
 InputMessage & 0 & 0 & 0 &------ &------ \\
 \hline 
 JobUnitID & 0 & 0 & 0 &------ &------ \\
 \hline 
 JobUnitSize & 0 & 0 & 0 &------ &------ \\
 \hline 
 MovingAverageLeafsDistributablePolicy & 11 & 0 & 6 &------ &------ \\
 \hline 
 OutputMessage & 0 & 0 & 0 &------ &------ \\
 \hline 
 Packet & 0 & 0 & 0 &------ &------ \\
 \hline 
 PacketContainer & 0 & 0 & 0 &------ &------ \\
 \hline 
 Port & 0 & 0 & 0 &------ &------ \\
 \hline 
 RecursionManager & 74 & 12 & 52 & 1.423 & 0.231 \\
 \hline 
 RecursiveProcessor & 5 & 0 & 8 &------ &------ \\
 \hline 
 Sigmoid & 28 & 4 & 25 & 1.120 &------ \\
 \hline 
 anonymous & 15 & 3 & 9 &------ &------ \\
 \hline 
 stack & 0 & 0 & 0 &------ &------ \\
 \hline 
 uint & 0 & 0 & 0 &------ &------ \\
 \hline 

\end{tabular}

\section{Object Oriented Design}
\begin{itemize}
\item WMC = Weighted methods per class\\ 
 The sum of a weighting function over the functions of the module. Two different weighting functions are applied: WMC1 uses the nominal
weight of 1 for each 
function, and hence measures the number of functions, WMCv uses a weighting function which is 1 for functions accessible to other modules, 0
for private 
functions. 
\item DIT = Depth of inheritance tree\\ 
 The length of the longest path of inheritance ending at the current module. The deeper the inheritance tree for a module, the harder it may
be to predict its 
behaviour. On the other hand, increasing depth gives the potential of greater reuse by the current module of behaviour defined for ancestor
classes. 
\item NOC = Number of children\\ 
 The number of modules which inherit directly from the current module. Moderate values of this measure indicate scope for reuse, however
high values may 
indicate an inappropriate abstraction in the design. 
\item CBO = Coupling between objects\\ 
 The number of other modules which are coupled to the current module either as a client or a supplier. Excessive coupling indicates weakness
of module 
encapsulation and may inhibit reuse. 

\end{itemize}
 The label cell for each row in this table provides a link to the module summary table in the detailed report for the module in question 

\begin{tabular}{|c|c|c|c|c|c|}
\hline 
Module Name &WMC1 &WMCv &DIT &NOC &CBO \\
 \hline 
 Address & 0 & 0 & 0 & 0 & 1 \\
 \hline 
 BySizeResultSender & 3 & 3 & 1 & 0 & 3 \\
 \hline 
 ChainableSender & 4 & 4 & 0 & 1 & 2 \\
 \hline 
 ChildrenFunctors & 0 & 0 & 0 & 0 & 1 \\
 \hline 
 ClientProcessor & 0 & 0 & 0 & 1 & 1 \\
 \hline 
 DeserializerFunctor & 1 & 1 & 0 & 0 & 3 \\
 \hline 
 DistributableJobImplementation & 0 & 0 & 0 & 1 & 1 \\
 \hline 
 DistributableRecursiveProcessor & 10 & 10 & 1 & 1 & 7 \\
 \hline 
 DistributeAlwaysAllPolicy & 1 & 1 & 0 & 0 & 1 \\
 \hline 
 DistributeRandomPolicy & 1 & 1 & 0 & 0 & 1 \\
 \hline 
 FinalSender & 4 & 4 & 0 & 1 & 2 \\
 \hline 
 FixedLeafsDistributablePolicy & 2 & 1 & 1 & 0 & 2 \\
 \hline 
 FuDRManager & 7 & 2 & 1 & 0 & 5 \\
 \hline 
 FuDRProcessor & 5 & 2 & 2 & 0 & 8 \\
 \hline 
 FuDSender & 3 & 3 & 0 & 0 & 1 \\
 \hline 
 InmediatelySender & 3 & 3 & 1 & 0 & 3 \\
 \hline 
 InputMessage & 0 & 0 & 0 & 0 & 3 \\
 \hline 
 JobUnitID & 0 & 0 & 0 & 0 & 1 \\
 \hline 
 JobUnitSize & 0 & 0 & 0 & 0 & 1 \\
 \hline 
 MovingAverageLeafsDistributablePolicy & 2 & 1 & 1 & 0 & 2 \\
 \hline 
 OutputMessage & 0 & 0 & 0 & 0 & 2 \\
 \hline 
 Packet & 0 & 0 & 0 & 0 & 3 \\
 \hline 
 PacketContainer & 0 & 0 & 0 & 0 & 4 \\
 \hline 
 Port & 0 & 0 & 0 & 0 & 1 \\
 \hline 
 RecursionManager & 9 & 8 & 0 & 1 & 5 \\
 \hline 
 RecursiveProcessor & 1 & 1 & 0 & 1 & 1 \\
 \hline 
 Sigmoid & 3 & 1 & 0 & 2 & 3 \\
 \hline 
 anonymous & 3 & 2 & 0 & 0 & 0 \\
 \hline 
 stack & 0 & 0 & 0 & 0 & 1 \\
 \hline 
 uint & 0 & 0 & 0 & 0 & 9 \\
 \hline 

\end{tabular}

\section{Structural Metrics Summary}
\begin{itemize}
\item FI = Fan-in\\ 
 The number of other modules which pass information into the current module. 
\item FO = Fan-out\\ 
 The number of other modules into which the current module passes information 
\item IF4 = Information Flow measure\\ 
 A composite measure of structural complexity, calculated as the square of the product of the fan-in and fan-out of a single module.
Proposed by Henry and 
Kafura. 

\end{itemize}
 Note that the fan-in and fan-out are calculated by examining the interface of each module. As noted above, three variants of each each of
these measures are 
presented: a count restricted to the part of the interface which is externally visible, a count which only includes relationships which
imply the client module 
needs to be recompiled if the supplier's implementation changes, and an inclusive count The label cell for each row in this table provides a
link to the 
relationships table in the detailed report for the module in question 

\begin{tabular}{|c|c|c|c|c|c|c|c|c|c|}
        \hline
        Module Name & \multicolumn{3}{|c|}{Fan-out} & \multicolumn{3}{|c|}{Fan-in} & \multicolumn{3}{|c|}{IF4} \\
        \hline 
 &vis &con &inc &vis &con &incl &vis &con &inc \\
 \hline 
 Address & 1 & 0 & 1 & 0 & 0 & 0 & 0 & 0 & 0 \\
 \hline 
 BySizeResultSender & 0 & 0 & 0 & 3 & 3 & 3 & 0 & 0 & 0 \\
 \hline 
 ChainableSender & 1 & 1 & 1 & 1 & 0 & 1 & 1 & 0 & 1 \\
 \hline 
 ChildrenFunctors & 1 & 0 & 1 & 0 & 0 & 0 & 0 & 0 & 0 \\
 \hline 
 ClientProcessor & 1 & 1 & 1 & 0 & 0 & 0 & 0 & 0 & 0 \\
 \hline 
 DeserializerFunctor & 2 & 0 & 2 & 1 & 0 & 1 & 4 & 0 & 4 \\
 \hline 
 DistributableJobImplementation & 1 & 1 & 1 & 0 & 0 & 0 & 0 & 0 & 0 \\
 \hline 
 DistributableRecursiveProcessor & 1 & 1 & 1 & 5 & 3 & 6 & 25 & 9 & 36 \\
 \hline 
 DistributeAlwaysAllPolicy & 0 & 0 & 0 & 1 & 1 & 1 & 0 & 0 & 0 \\
 \hline 
 DistributeRandomPolicy & 0 & 0 & 0 & 1 & 1 & 1 & 0 & 0 & 0 \\
 \hline 
 FinalSender & 1 & 1 & 1 & 1 & 0 & 1 & 1 & 0 & 1 \\
 \hline 
 FixedLeafsDistributablePolicy & 0 & 0 & 0 & 2 & 2 & 2 & 0 & 0 & 0 \\
 \hline 
 FuDRManager & 0 & 0 & 0 & 5 & 4 & 5 & 0 & 0 & 0 \\
 \hline 
 FuDRProcessor & 0 & 0 & 0 &\emph{ 8}
 & 4 & 8 & 0 & 0 & 0 \\
 \hline 
 FuDSender & 0 & 0 & 0 & 1 & 0 & 1 & 0 & 0 & 0 \\
 \hline 
 InmediatelySender & 0 & 1 & 1 & 2 & 1 & 2 & 0 & 1 & 4 \\
 \hline 
 InputMessage & 3 & 0 & 3 & 0 & 0 & 0 & 0 & 0 & 0 \\
 \hline 
 JobUnitID & 1 & 1 & 1 & 0 & 0 & 0 & 0 & 0 & 0 \\
 \hline 
 JobUnitSize & 1 & 1 & 1 & 0 & 0 & 0 & 0 & 0 & 0 \\
 \hline 
 MovingAverageLeafsSigmoid & 0 & 0 & 0 & 1 & 2 & 2 & 0 & 0 & 0 \\
 \hline 
 OutputMessage & 2 & 0 & 2 & 0 & 0 & 0 & 0 & 0 & 0 \\
 \hline 
 Packet & 3 & 0 & 3 & 0 & 0 & 0 & 0 & 0 & 0 \\
 \hline 
 PacketContainer & 4 & 1 & 4 & 0 & 0 & 0 & 0 & 0 & 0 \\
 \hline 
 Port & 1 & 1 & 1 & 0 & 0 & 0 & 0 & 0 & 0 \\
 \hline 
 RecursionManager & 1 & 1 & 1 & 4 & 2 & 4 & 16 & 4 & 16 \\
 \hline 
 RecursiveProcessor & 1 & 1 & 1 & 0 & 0 & 0 & 0 & 0 & 0 \\
 \hline 
 Sigmoid & 2 & 2 & 2 & 0 & 1 & 1 & 0 & 4 & 4 \\
 \hline 
 anonymous & 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 \\
 \hline 
 stack & 1 & 1 & 1 & 0 & 0 & 0 & 0 & 0 & 0 \\
 \hline 
 uint &\emph{ 7}
 &\emph{ 9}
 & 9 & 0 & 0 & 0 & 0 & 0 & 0 \\
 \hline 

\end{tabular}

\section{Other Extents}


\begin{tabular}{|c|c|c|c|c|}
\hline 
Location &Text &LOC &COM &MVG \\
 \hline 
common.h:1
 &$<$file scope items$>$ & 24 & 49 & 0 \\
 \hline 
recursive\_functor.h:1
 &$<$file scope items$>$ & 5 & 39 & 0 \\
 \hline 
serializable\_recursive\_functor.h:1
 &$<$file scope items$>$ & 4 & 38 & 0 \\
 \hline 
recursion\_manager.cpp:1
 &$<$file scope items$>$ & 2 & 38 & 0 \\
 \hline 
l4\_server\_app.h:1
 &$<$file scope items$>$ & 4 & 38 & 0 \\
 \hline 
recursion\_manager.h:1
 &$<$file scope items$>$ & 4 & 39 & 0 \\
 \hline 
by\_size\_result\_sender.cpp:1
 &$<$file scope items$>$ & 2 & 38 & 0 \\
 \hline 
distributable\_recursive\_processor.cpp:1
 &$<$file scope items$>$ & 4 & 41 & 0 \\
 \hline 
distribution\_policy.cpp:1
 &$<$file scope items$>$ & 3 & 38 & 0 \\
 \hline 
by\_size\_result\_sender.h:1
 &$<$file scope items$>$ & 4 & 38 & 0 \\
 \hline 
deserializer\_functor.h:1
 &$<$file scope items$>$ & 4 & 38 & 0 \\
 \hline 
distributable\_recursive\_processor.h:1
 &$<$file scope items$>$ & 4 & 38 & 0 \\
 \hline 
distribution\_policy.h:1
 &$<$file scope items$>$ & 7 & 38 & 0 \\
 \hline 
l4\_client\_app.h:1
 &$<$file scope items$>$ & 4 & 38 & 0 \\
 \hline 
recursive\_processor.h:1
 &$<$file scope items$>$ & 4 & 38 & 0 \\
 \hline 
result\_sender.h:1
 &$<$file scope items$>$ & 4 & 38 & 0 \\
 \hline 
fud\_rmanager.cpp:1
 &$<$file scope items$>$ & 5 & 38 & 0 \\
 \hline 
fud\_rmanager.h:1
 &$<$file scope items$>$ & 4 & 38 & 0 \\
 \hline 
fud\_result\_sender.cpp:1
 &$<$file scope items$>$ & 5 & 38 & 0 \\
 \hline 
fud\_rprocessor.cpp:1
 &$<$file scope items$>$ & 5 & 38 & 0 \\
 \hline 
fud\_result\_sender.h:1
 &$<$file scope items$>$ & 4 & 38 & 0 \\
 \hline 
fud\_rprocessor.h:1
 &$<$file scope items$>$ & 4 & 38 & 0 \\
 \hline 

\end{tabular}

\section{About CCCC}

This report was generated by the program CCCC, which is FREELY REDISTRIBUTABLE but carries NO WARRANTY. \\

CCCC was developed by Tim Littlefair. as part of a PhD research project. This project is now completed and descriptions of the findings can
be accessed at \url{http://www.chs.ecu.edu.au/~tlittlef}. \\

User support for CCCC can be obtained by mailing the list:
\begin{center}cccc-users@lists.sourceforge.net\end{center}

Please also visit the CCCC development website at:
\begin{center}\url{http://cccc.sourceforge.net}\end{center}